Code Review: Test enhancements for lineage specs with comprehensive entity creation and visibility checks. However, four important issues remain: typo 'Store Procedure' should be 'Stored Procedure', critical logic change from OR to AND in path preservation that alters filtering behavior, empty pagination state at nodeDepth=0, and significant code duplication between ES and OS lineage builders despite shared abstract logic.

1. ⚠️ Bug: Typo 'Store Procedure' should be 'Stored Procedure'
   Files: openmetadata-ui/src/main/resources/ui/playwright/utils/common.ts:156

   The search index mapping key `['Store Procedure']` is missing the 'd'. The rest of the codebase (e.g., `importUtils.ts`, class names) consistently uses 'Stored Procedure'. This mismatch will cause entity type lookups to fail for stored procedures, as `getEntityTypeSearchIndexMapping('Stored Procedure')` will return `undefined`.

   Suggested fix:
   Change:
       ['Store Procedure']: 'storedProcedure',
   To:
       ['Stored Procedure']: 'storedProcedure',

2. 💡 Quality: Missing afterAll cleanup for table created in beforeAll
   Files: openmetadata-ui/src/main/resources/ui/playwright/e2e/Pages/Lineage/DataAssetLineage.spec.ts:455-458, openmetadata-ui/src/main/resources/ui/playwright/e2e/Pages/Lineage/PlatformLineage.spec.ts:35-38

   The newly added `test.beforeAll` in the 'Lineage Settings modal' block (DataAssetLineage.spec.ts:455-458) creates a `TableClass` entity but there is no corresponding `test.afterAll` to delete it. The same issue exists in PlatformLineage.spec.ts (line 35-38) where the table creation was moved to the top-level scope without adding cleanup.
   
   While this follows the existing pattern in the file (no other describe block has afterAll either), it leaves orphaned test entities in the system between runs, which can cause flaky tests or data buildup in CI environments.

   Suggested fix:
   // DataAssetLineage.spec.ts — add after the beforeAll block:
   test.afterAll(async ({ browser }) => {
     const { apiContext } = await getDefaultAdminAPIContext(browser);
     await table.delete(apiContext);
     await afterAction();
   });
   
   // Same pattern for PlatformLineage.spec.ts

3. ⚠️ Bug: requiresPathPreservation logic changed from OR to AND

   The condition for enabling path preservation in `buildQueryContext` was changed from `preservePaths || hasQueryFilter` to `preservePaths && hasNodeLevelFilters`. Previously, any non-empty query filter automatically enabled path preservation (ensuring filtered-out intermediate nodes still had their connecting edges preserved). Now, path preservation requires the caller to **explicitly** set `preservePaths=true` **and** have node-level filters present.
   
   If any caller issues a request with a node-level query filter (e.g., owner, tags) but does not set `preservePaths=true`, intermediate connecting paths will no longer be preserved. This could cause lineage graphs to appear disconnected when node-level filters remove intermediate nodes that are needed to show the path between the root and matching deeper nodes.

   Suggested fix:
   If the intent is to always preserve paths when node-level filters are active (which was the prior behavior), use OR:
   
   boolean requiresPathPreservation =
       (request.getPreservePaths() != null && request.getPreservePaths())
           || hasNodeLevelFilters;

4. 💡 Edge Case: Empty currentDirectionDepthCounts at nodeDepth=0 pagination

   When `request.getNodeDepth() == 0` and `request.getIncludePaginationInfo()` is true, `buildEntityCountPaginationInfo` is called with `currentDirectionDepthCounts` still set to its initial empty `LinkedHashMap`. For the requested direction, this means the pagination info will only show `depth 0 -> 1` (the root), with no depth counts for deeper levels in that direction. The opposite direction counts are fetched correctly.
   
   This is likely correct behavior (at depth 0 you only see the root), but it means the pagination info won't show how many entities exist at deeper depths for the current direction until the user navigates to a deeper depth. If the intent is to always provide full depth counts in pagination info, the current direction's counts need to be computed even at nodeDepth=0.

5. 💡 Quality: ES and OS lineage builders remain near-identical copies

   Despite `AbstractLineageGraphBuilder` extracting common logic, `ESLineageGraphBuilder` and `OSLineageGraphBuilder` still have ~1600 lines each of nearly identical code (e.g., `searchLineageByEntityCountInternal`, `getFilteredDepthCounts`, `getEntitiesAtSpecificDepthWithPagination`, `buildEntityCountPaginationInfo`, `getEntityCountDepthCounts`). Every change in this PR had to be applied twice. Consider extracting more shared logic into the abstract base class using template methods, with only the client-specific search execution delegated to subclasses.